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^ (57) Abstract: The invention is directed to a communication network wherein a direct tunnel may be formed between a user equip- 
2 -fnenl and a gateway support node, bypassing an intermediate serving support node. If, however, the gateway node should be outside 
of the actual communication network to which the user equipment is connected, a two-tunnel concept is used wherein a tunnel is 
^ provided between the user equipment and the serving support node. Likewise, when receiving a request for Lawful Interception, the 
tunnel formed between the user equipment and the gateway node is reconfigured to be directed to the serving node for guiding all 
^ user traffic and control signaling via this serving node. (Fig. 4) 
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Method and Device for attaching a User Equipment to a 
Telecommunication Network 



Field of the Invention 

The present invention relates to a method and device f-or 

attaching a user equipment to a telecommunication network using 
a tunnel connection. 

Background of the Invention 

When attaching a user equipment to a communication system based 
on GSM (Global system for mobile communication) , for instance 
GPRS (general packet radio service; see for instance European 
standard (telecommunications series) EN 301 113) or UMTS 
(universal mobile telecommunications system; see for instance 
ETSI standard ES 201 385) standard], the user equipment usually 
sends an attachment request and Packet Data Protocol context 
activation request to a support node and will then be attached 
to the access network, e.g. GSM PLMN (public land mobile 
network) or UMTS PLMN, and connected to an external network 
(e.g. Internet). The access network provides the connection 
for instance by attributing a bearer channel. In a packet 
switched telecommunication system such as GPRS or UMTS, the 
data including user traffic data and control (signalling) data 
are normally sent from the user equipment to a serving support 
node which may send this data to a second support node, such as 
a gateway support node, for transmitting the communication to a 
receiving party which may be located in an an external network. 

In addition, tunneling mechanisms are well-known especially 
over IP. An example of such tunneling mechanism is GTP (GPRS 
Tunneling protocol which in its version 1 identify a tunnel 
with a destination address (tunnel endpoint address, Ipv4 or 
Ipv6 for GTP) indicating the node of processing card handling 
the tunnel and a Tunnel End Point Identifier (TEID) 
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indentifying the tunnel within this entity. Every entity sends 
packet with the TEID allocated by the other tunnel end and 
receive packets with the TEID it has itself allocated. 
Usually, there is the overall tendency to reduce the traffic 
5 load in communication networks. However, different situations 
have to be taken into account such as a request for 
transmitting and receiving a . communication to and from another 
communication network, or a request for Lawful Interception 
(monitoring) of a party or user equipment by a law enforcement 
10 agency authorised to monitor this party or user equipment. 

Summary of the Invention 

15 The present invention aims at providing a method and device for 
connecting a user equipment to an external network wherein the 
load on the access network can be reduced, preferably, however, 
without negatively affecting the operability of the network or 
without affecting the possibility of Lawful Interception. 

20 

The present invention provides methods and/or devices as 
defined in the claims. 

In particalar, the present invention provides a method and 
25 device for connecting a user equipment to an external network 
through an access network having at least two support nodes 
wherein, under normal circumstances, the user equipment will be 
directly connected, via a tunnel connection, to a second 
support node bypassing its assigned support node. 

30 

.This direct tunnel connection reduces the total traffic in the 
network as the first support node does not need to handle the 
user traffic of the user equipment under normal circumstances. 
In addition, this connection leads to a certain increase of the 
35 overall traffic speed as the first support node and its 
inherent (small) delay is bypassed. 
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However, in order to ensure a proper operability and 
functionality, the invention proposes that said first support 
node checks defined trigger to determine if one tunnel should 
be established as under normal circumstance or if two tunnels 
should be established as at least one defined trigger is met. 



Typically in order to ensure a proper operability and 
functionality, the following triggers are checked: 

- support of special services for a given user such as CAMEL 
services, and check if these services would be delivered 
also with one tunnel ; 

- need to perform Lawful interception for a given user; 

- Interoperability between the second support node selected 
and the controller such as RNC, in order to guarantee that 

15 both support same GTP tunnel version; 

- Location of the second support node in another PLMN than the 
first support node which may determine the need of 
collecting charging data in the same PLMN as the first 
support node; 

Location of the second support node far away from the 
support node, in which case two tunnels may be preferred to 
avoid updating tunnels (due to user mobility) to a far away 
second support node too often. This is the principle of 
hierarchical mobility. 



The invention is about using one or more (in any arbitrary 
combination) of these triggers to make the decision how many 
tunnels to establish. The support node should offer the 
possibility to use these . triggers and the operator should 
configure which triggers are relevant to support its operation 
and services. 

A first implementation of the invention discussed below in more 
detail, describes how a simple check can be used for the two 
last. above-mentioned triggers in order to always collecting 
charging data in the same PLMN as the first support node and 
support hierarchical mobility. 
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In this or a further implementation of the invention, first 
support node checks whether or not the second support node is 
part of the same network as the first support node. Only in 
this case, the direct tunnel connection is preferably 
S established. If the second support node should form part of 
another PLMN, no direct tunnel connection is provided. To the 
contrary, all traffic including the user data (user traffic 
data) and the control data is sent to the first support node 
which may then address the second support node (lying outside 
10 of the own network) by means of a tunnel connection or in a 
different customary manner. This provides the advantage of 
ensuring that all traffic goes to at least one support node in 
the network assigned to the user equipment so that all controls 
including charging and the like can be properly handled. 

15 

It shall be understood that the provision of one tunnel still 
means that two links from the user equipment are provided. One 
signaling linkleads from the user equipment to the first 
support node and transports all control data (signalling flow) 

20 whereas the second data link is formed between the user 

equipment and the second support node (for instance, residing 
in the same PLMN) and handles all user data apart from the 
control data. In a system such as UMTS, this data link is made 
from a radio bearer from the user equipment to the RNC and from 

25 a tunnel between the RNC and the second support node. In other 
systems, for instance using mobile IP for mobility, the tunnel 
may be established between the user equipment and the second 
support node (Home Agent) . 

30 This dual link structure provides the advantage of directly 

handling the user data traffic between the user equipment and 
the second support node bypassing the first support node, which 
leads to a reduction of the delay caused thereby, and of the 
traffic load which would otherwise additionally have to be 

35 handled. On the other hand, the first support node always 

receives and transmits the control data from and to the user 
equipment and therefore is always aware of the user equipment 
activities. 
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In case of receiving a request for Lawful Interception of the 
user equipment (which may be a mobile phone, a data station 
such as a portable computer, or the like) , the first support 
node is able to reconfigure the connection status of the user 
equipment in such a manner that furtheron user data are 
transferred via the first support node which will then send the 
data to the intercepting party, for instance via a Lawful 
Interception gateway (LIG) for monitoring purposes. This 
reconfiguration of the traffic pathes can be effected very 
quickly and efficiently so that the intercepted party does not 
recognize any surprising changes of data transmission. 

In case the RNC needs to release the radio link to the user 
equipment (such a need may arise in UMTS to optimise the radio 
signaling, or to synchronise states of a UE (user equipment) 
out of coverage), the controller such as RNC will perform a 
release procedure, e.g. Iu release procedure, toward the first 
support node (e.g. SGSN) . In such case, if one tunnel is 
established to a second support node such as GGSN, the first 
support node is able to reconfigure the connection status of 
the user equipment in such a manner that furtheron user data 
are transferred via the first support node. . 

Note that reconfiguring the connection status of the user 
equipment in such a manner that furtheron user data are 
transferred via the first support node refers in a GPRS/UMTS 
system to the PDP context modification procedure which can be 
used to modify the destination address of the tunnel. 



Brief Description of the Drawings " " - - . 

Fig. 1 illustrates a schematic embodiment of a basic structure 
35 of a telecommunication network; • . 

Fig. 2 illustrates a process flow in one embodiment of the 
invention; 
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Fig. 3 shows a process flow in the same or a further embodiment 
of the invention; 

5 Fig. 4 illustrates the signalling data flow when attaching a 
user equipment to a telecommunication network; 

Fig. 5 shows the message flow to and between support nodes and 
a control point in another embodiment of the invention; 

10 

Fig. 6 shows the message flow to and between support nodes and 
a control point in a further embodiment of the invention; and 

Fig. 1 shows an alternative of the message flow to and between 
15 support nodes and a control point in the embodiment according 
to Figs. 5 and 6. 

Detailed Description of preferred Embodiments of the Invention 

20 

Fig. 1 shows a basic structure of a telecommunication network 
implemented as an UMTS system. However, the network may also 
have any other structure of a packet switched data transmission 
system like GPRS, or any other appropriate system structure. 

25 The system of Fig. 1 comprises a user equipment 1 which may be 
a mobile phone or a data station or the like. Actually, a 
plurality of user equipments 1 will be. present which 
communicate via the network. For effecting a transmission 
(originating or • terminating a call or data transmission) , the 

30 user equipment 1 transmits/receives commands and user data via 
a controller controlling the user equipment access, e.g. a 
Radio Network Controller (RNC) 2 (or a base station 
controller), to a first support node 3 which serves as a 
serving support node handling the communication between the 

35 user equipment 1 and the GGSN. The serving support node 3 may 
communicate with a second support node 4 such as a gateway 
node, or with a gateway support node 5 of another network such 
as a PLMN, for instance when the call/data transmission is to 
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be sent to an external network such as public Internet or 
Intranet. The data traffic traverses the gateway support node. 

Fig. 2 illustrates the basic steps of attaching a user 
equipment and getting a connection to an external network 
according to one embodiment of the invention. In step SI, the 
••user equipment 1 (Fig. 1) sends a request for attaching and 
activating a PDP context, via the controller providing access 
for the user equipment such as RNC 2, to the serving support 
node 3. The support node 3 effects a check to determine if one 
or two tunnel should be established. 

The possible checks will now be described in detail: 

Support of special services for a given user such as CAMEL 
services, and check if these services would be delivered 
also with one tunnel. 
The first support node such as SGSN will check from the 
subscriber data, if particular services are activated. A first 
example of service is CAMEL pre-paid and a second is SoLSA 
(Support of Localised Service Area) . 

The use of CAMEL for this user is indicated by the Camel 
Subscription Information, and active detection points. When 
receiving the PDP context activation request from the UE, the 
SGSN will check if a detection point is activated for this 
event. If not, one tunnel can be established based on this 
trigger. If yes , the SGSN will interrogate the Service Control 
Point (SCP) to learn how to proceed. If the SCP requests the 
SGSN to report a data, volume, in a first preferred option, the 
SGSN establishes two tunnels, so that the. data volume is 
accessible in its data processing part. 

In a second preferred option, the SGSN first checks the 
capability of a second node such as GGSN to report this data 
volume. This is made by adding in the GTP Create PDP Context 
Request message an optional field "(e.g. Data Volume Threshold, 
as defined in relation with Fig. 5)» requesting a data volume 
report (based on a volume limit as defined by the SCP). if the 



7 



WO 02/03725 



PCT/EP00/06275 



GGSN supports such capability, it will add in the GTP Create 
PDP Context Response message an optional field indicating that 
the request for the data volume report was accepted. If this 
optional field is not returned by the GGSN indicating that the 
5 GGSN does not support this capability, the SGSN establishes two 
tunnels. 

The implementation for the second service SoLSA, is based on 
checking from subscriber data if SoLSA is a subscribed service. 
If it is, the amount of data sent in different Localised 
10 Service Areas should be indicated, and only SGSN will detect 
when an LSA change. Therefore, the SGSN should establish two 
tunnels for SoLSA users. 

- Need to perform Lawful interception (LI) for a given user: 
15 The SGSN checks during the attach procedure if new UE (User 

Equipment) should be intercepted or not. In a normal case, the 
SGSN always establishes two tunnels for intercepted UE so it 
can forward it to LIG (Lawful Interception Gateway) . However, 
if the GGSN used supports LI and is located in the same 
20 country, the SGSN may decide , to establish one tunnel (if no 
need to have two. tunnels arises from other triggers).. 

- ' Interoperability between the second support node selected 

and the controller such as RNC, in order to guarantee that 

25 both support same GTP tunnel version. 

A particular interoperability problem arises when the RNC 
supports only GTP version 1 and the GGSN only GTP version 0. 
The SGSN detects this situation when sending a GTP create PDP 
context message to the GGSN using GTP version 1 and receiving 

30 "GTP message version not supported". In this case, two. tunnels, 
have to be established as GGSN. and RNC are not able to 
communicate directly. 

- Location of the second support node in another PLMN than the 
35 first support node which may determine the 'need of 

collecting- charging data in the same PLMN as the first 
support node. 
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A PLMN operator offering radio access to a user equipment using 
a GGSN in a different PLMN may or may not trust on this second 
PLMN operator charging information. Therefore, the SGSN should 
check if the GGSN belongs to a trusted PLMN from a 
preconfigured list of trusted PLMNs (and by default one PLMN 
always trust itself).. If it does not belong to the list, two 
tunnels shall be established so the first PLMN operator can 
itself monitor the user data traffic. . 

- Location of the second support node far away from the first 
support node, in which case two tunnels may be preferred to 
avoid updating tunnels (due to user mobility) to a far away 
second support node too often. This is the principle of 
hierarchical mobility. 
When the user equipment is moving, it may change its serving 
RNC, and such change implies an update of the other tunnel end 
to indicate the new tunnel destination address. Such update may 
be heavy and create delay if the other end is situated far 
away. Therefore, it is not efficient to establish one tunnel 
toward a far away GGSN. Therefore to maintain efficient 
mobility, the SGSN will check if the GGSN belongs to a pre- 
configured list of near-by GGSN. If it does not belong to this 
list, two tunnels should be established. 

It should be noted, that the two last checks can be combined 
(trusted and near-by GGSN) by having a single list of PLMNs 
toward which one tunnel may be created. 

If none of these checks determines that two tunnels should be 
established, then the SGSN will establish a single tunnel. 

This(ese) check (s) is (are) effected in order to ensure that the 
tunnel connection to be established, by the first node 3, 
between the user equipment 1 and the second support node 4 is 
at least handled by a support node situated in the same network 
so as. to gather all information necessary for properly 
controlling and operating the network such as correctly 
calculating the call charges. When the first support node 3 
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detects that the call is to be transmitted to a second node 4 
being situated in the same network, it establishes a direct 
tunnel connection between the user equipment 1 and the second 
support node 4 via the base station 2 but bypassing the support 
5 node 3 (step S3) . 

When, to the contrary, the first node 3 detects, in step S2, 
that two tunnels should be used (for instance the gateway 
support node 5 is a node of another PLMN) , the process proceeds 

10 to step S4 wherein the first support node 3 prepares two 
tunnels, one leading from the user equipment (or the base 
station RNC 2) to the support node 3, and the other leading 
from the support node. 3 to the external support node such as 
support node 5. The handling and preparation of tunnels as such 

15 are known processes which are defined, for instance, in 
European standard ETSI EN 301 347, 

When using only one tunnel, the additional processing necessary 
when having two tunnels, and the extra node junction of support 
20 node 3 can be omitted, with a corresponding increase in speed 
and decrease in network load. 

Fig. 3 shows a process for handling a request for a Lawful 
Interception. Here, in the normal case, a split tunnel 

25 situation is present wherein the support node 3 has established 
a direct tunnel from base station 2 to support node 4. However, 
this tunnel is used only for user traffic, that is all data 
sent from and received by abuser excluding control data, i.e. 
signalling data. The control data are still transmitted between 

30 base station 2 and support node 3. In order to provide this . 

situation, the support node 3 gives the address of the support 
node 4 as user traffic address when reserving Iu bearers. 
Therefore, the RNC 2 still assumes that it is exchanging user 
data with the support node 3 although the actual user data 

35 tunnel directly goes to the support node 4. However, the 

control data is still" transmitted to and handled by the support 
node 3. 
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In case of a request for a Lawful Interception (LI), see for 
instance the ETSI specification, the support node 3 preferably 
performs a radio access bearer modification (RANAP), requesting 
the change of the GTP tunnel (s) for one user. This tunnel (s) is 
then routed via the support .node 3 so that now all data flow 
via this node 3 and Lawful Interception is possible by 
monitoring the data flowing via node 3. The tunnel endpoint 
address and TEID stored in GGSN is updated to the address and 
TEID of SGSN 3. Likewise, the RNC is updated to store the 
address and TEID of node 3 as tunnel endpoint address and TEID. 
Note that SGSN may have different TEIDs for uplink and 
downlink. 

Fig. 3 shows this process in greater detail. In step S5, a 
direct tunnel related to a user (preferably only for user data 
but not for control data for always giving the support node 3 
control over the data flow for redirecting same to itself) is 
established between RNC 2, respectively, and the second node 4. 
When a request for Lawful Interception is received by support 
node 3 for this user, step S6, the process proceeds to step S7. 
If no such request is received, the normal operation remains 
unchanged. In step SI, the direct tunnel existing between the 
user equipment (in more detail, the RNC 2) and the second node 
4 is canceled. This may be effected by sending a request for 
changing the radio access bearer from node 3 to RNC 2, for 
instance by performing a RANAP radio access bearer 
modification, and by updating the address stored in node 4 to 
the address of node 3- This request demands a change of the 
user tunnel. The support node 3 now will give its own address 
as address of user packet data to be sent from and to RNC 2 
and, thus, from and to user equipment 1. Now, all traffic 
including user data and control data are handled by the first 
node 3. Therefore, this node 3 can send all transmitted user 
data to a Lawful Interception gateway (LIG) such as defined in 
the ETSI standard, for instance. .The Lawful Interception 
according to step S8 is now able to monitor the total 
communication sent and received from and by the user equipment 
1. 
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Fig. 4 illustrates the signaling and control flow effected for 
establishing a direct tunnel between the user equipment 1 (or 
the control station RNC 2) and the second support node (GGSN) 4 
5 when activating the user equipment. Before starting any L3 

signaling, the RRC connection (receiver ready connection) has 
to be established in a known manner (see standards for RRC 
procedures)'. This RRC connection establishment may be performed 
before or after the decision of the user equipment 1 to 

10 activate a new context (see for instance standard ETSI EN 301 
347) . The signaling messages shown in Fig. 4 are as follows: 
Step 1-: the user equipment 1 sends an "activate PDP context 
request" to the first support node 3 which contains the data 
items Protocol Discrimator, Transaction Identifier, Activate 

15 PDP Context Request Message Identity, Requested NSAPI, 

Requested PDP Address including PDP Type, Quality of Service 
QoS requested, Protocol Configuration Option (optional) , 
- Access Point Name APN (optional) , and further parameters. 
This message may be transparently encapsulated, on the Iu 

20 interface, in a RANAP direct transfer request message. There 

may also security procedures be carried out between the support 
node 3 and the user equipment 1. 

The support node 3 checks the rights of the subscriber. When 
25 determining that the "activate PDP context request" is valid, 
the support node 3 derives the APN to be used and uses it to 
interrogate the DNS (Domain Name Server) functionality for 
learning the address of the associated second support node 4 . 
which may be a gateway support node for communicating with 
30 other networks. The DNS functionality returns the IP (Internet 
protocol) address of the second support node 4 . The first 
support node 3. creates a TEID for the tunnel. The support node 
3 furthermore determines whether or not it has to downgrade the 
requested QoS. 

35 

Thereafter, the support node 3 decides whether or not the 
following steps 2. and 3. should be performed before or after 
steps 5. and 6. Preferably, the step's 2. and 3. are performed 
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before the steps 5. and 6. as the controller 2 (which may e.g. 
be a radio network subsystem) and corresponds to RNC of Fig. 1) 
is more likely to downgrade the quality of service QoS than the 
second support node 4 . 

Step 2.: The support node 3 now sends a radio access bearer 
(RAB) assignment request to the user equipment access' 
controller such as RNS, RNC or Serving RNC 2 which request 
corresponds to a PDP (packet data protocol) context activation 
request and contains the parameters IMSI, NSAPI, TEID for 
support node 3, the IP address of support node 3 (SGSN) , QoS 
negotiated 1 (including reordering as required). In Fig. 4, 
support node 3 is designated as 3G-SGSN which specifies a third 
generation GPRS support node of an UMTS network. However, the 
15 support node 3 may also be of a different generation or of a 
general GSM type. The information sent in step 2. is used to 
set up a GTP (GPRS tunneling protocol) tunnel on the Iu 
interface. Normally, in GPRS phase 1, the reordering required 
is indicated by the gateway support node 4 . However, here 
preferably the user equipment 1 requests a reordering required. 



20 



Step 3.: The base station 2 uses the radio access bearer set up 
procedure to indicate, to the user equipment UE 1, the new 
bearer ID (identification) established, and the corresponding 
25 NSAPI with RRC signaling. As the support node 3 does not 

necessarily need information on the bearer ID, this information 
is preferably exchanged directly between the base station 2 and 
the user equipment 1. 



30 



Step 4.: The base station 2 .sends a RAB assignment complete 
message (i.e. PDP context activation response) to support node 
3 informing same on the completed radio access bearer set up. 
This message contains the following parameters: TID, flow label 
downlink for RNC 2, IP address for RNC 2, QoS negotiated 2 
35 (including reordering required) . The GTP tunnel is now open on 
the Iu interface. 
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In step 5., the support node 3 now initiates the procedure for 
setting up of the GTP tunnel on the Gn interface, by sending a 
"create PDP context request" message to the second support node 
4 which message contains information on the user PDP type and 
5 address, APN, QoS negotiated 2 (including reordering required)', 
filter parameters, selection mode, as well as TEID downlink for 
RNC 2 and IP address of RNC 2. It should be noted that sending 
these two last parameters, instead of the, SGSN ones is a novel 
feature. However, GGSN will not notice any difference. The data 
10 item "selection mode" indicates whether a subscribed APN was 
selected, or whether a non-subscribed APN sent by a mobile 
station such as user equipment 1, or a non-subscribed APN 
chosen by the first support node 3 was selected. 

15 Step 6.: The support node 4 then replies with the "Create PDP 
Context Response" message which includes the the IP address of 
support node 4, the TEID uplink for support node 4, the user 
PDP address, QoS negotiated 3 (including reordering required), 
PDP configuration options, and charging ID. Note that in case 

20 the QoS negotiated 3 is different from QoS negotiated 2, the 
support node 3 will probably renegotiate the Iu tunnel. 
However, this may not be necessary. Now, the GTP tunnel is open 
on the Gn interface. 

It should be noted that as described • earlier , this reply can 
25 activate a trigger, in particular if a certain feature such as 
data volume reporting is not supported by GGSN, or GTP version 
supported is not compatible with RNC. 

Step 7.: Support node 3 sends an "activate PDP context accept" 
30 message to the user equipment containing NSAPI (or possibly 

TI), PDP type, address, QoS negotiated 3 and PDP configuration 
options. This message is. relayed over the Iu' interface as a 
direct transfer request message. Now, the user equipment 1 
knows NSAPI, bearer ID and QoS profile for this bearer. 

35 • 

Step 8.: In parallel with step 7.,. the support node 3 sends a 
radio access bearer (RAB) establishment command for 
reconfiguration of the GTP tunnel on the Iu interface. The. 
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parameters are now IMSI, NSAPI, IP address of support node 4, 
TEID uplink for support node 4, QoS negotiated 3, and so on. 
The RNC 2 thus modifies the destination IP address and uplink 
TEID for this tunnel so that same is now directly open between 
RNC 2, that is the user equipment 1, and the second support 
node 4. The RNC 2 responds with a "RAB establishment complete" 
message to the first support node 3. 

This procedure is optimizing the transport efficiency by having 
only one tunnel instead of two. Furthermore, the charge 
collection and registration is done in the second support node, 
that is only one node per PLMN (collected CDR is performed in 
only one node) . 

In the signaling chart of Fig. 4, steps 5. and 6. may also be 
performed after steps 2., 3., 4. In addition, the tunnel 
•between the support nodes 3 and 4 may be modified at the end of 
the procedure. 

For implementing the process of Fig. 2, the support node 3 may 
check, before effecting step 8., whether the second support 
node 4 is part of its own network, or part of a different PLMN 
belonging or not to preconf igured PLMN list. If support node 4 
is part of the same network as support node 3, step 8. is 
effected as mentioned above. Otherwise, step 8 may be omitted. 
In addition, step 5. is then modified so as to indicate the 
TEID downlink for support node 3 (instead of RNC 2), and 
indicating the IP address of the support node 3 (instead of 
same of RNC 2). For optimizing the data handling, the check 
according to step S2 for Fig. 2 is preferably performed, by 
support node 3, before step 5. 

For implementing the procedure of Fig. 3, the support node 3, 
when receiving a request for Lawful Interception as indicated 
in step S6, performs a renewed radio access bearer 
reconfiguration procedure similar to step '8. so as to reset the 
tunnel in such a manner that two tunnels are formed, one 
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between RNC 2 and support node 3, and the second between 
support node 3 and support node 4. 

Fig. 5 shows details of a message flow in an embodiment of the 
invention which comprises a first support node 3 (SGSN) , a 
5 second support node 4 or 5 (GGSN) , and an additional 

controlling means 6 which here is implemented as a Service 
Control Point (SCP) of an Intelligent Network (IN). This 
embodiment provides a solution for e.g. correctly charging a 
subscriber having a prepaid account even when establishing a 
10 direct tunnel connection (GTP) in a CAMEL environment: Words 
printed in bold letters emphasize new functions or message 
contents. 

When the SGSN 3 receives an "Activate PDP Context Request" from 
15 a User Equipment (UE) , it sends a message "Initial DP Event / 

Event Report GPRS" to the SCP 6 which checks the conditions set 
for the UE. 

The SCP 6 may send "Apply Charging GPRS (Data Volume 
20 Threshold)" to -request data volume reporting from the SGSN 3. 
The SGSN 3 then addresses the GGSN -4 (or 5) with "Create PDP 
Context Request (Data Volume Threshold) " informing the GGSN 4 
on the Data Volume Threshold sent from the SCP 6. The GGSN 4 
performs the context creation steps and returns a "Create PDP 
25 Context Response"- In the "Create PDP Context Response", the 
GGSN sends an indication on whether it supports data volume 
reporting. Thereupon, the SGSN 3 sends a message "Activate PDP 
Context Accept" to the UE. 

30 The GGSN 4 informs the SGSN 3 on the data volume by sending a 
"Data Volume Notification Request (Data Volume) " The SGSN 3 
acknowledges this message by returning "Data Volume 
Notification Response". Finally, the SGSN 3 sends a report 
"Apply Charging Report GPRS (Data Volume)" to the SCP 6 which 

35 updates the subscriber account accordingly. 

Fig. 6 addresses a case where the charging criteria is reset or 
' changed when having a one-tunnel solution. Similar to the 
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embodiment of Fig. 5, this implementation comprises a first 
support node 3 (SGSN) , a second support node 4 or 5 (GGSN) , and 
an additional controlling means 6 which is a Service Control 
Point (SCP). of an Intelligent Network (IN). 

When the SCP 6 determines the necessity of informing the SGSN 
on the data volume threshold allowed for a certain subscriber, 
e.g. because of recharging of the subscriber account, or 
because of change of the admissible data volume to be sent or 
received by a subscriber, or the SGSN 3 or the SCP 6 are 
updated or the like, the SCP 6 sends a message "Apply Charging 
GPRS. (Data Volume Threshold)" to the SGSN 3 indicating the 
actually valid Data Volume Threshold. The SGSN 3 informs the 
GGSN 4 (or 5) thereon by sending an Update PDP Context Request 
(Data Volume Threshold) ". The GGSN 4 stores this Data Volume 
Threshold and acknowledges the message by returning "Update PDP 
Context Response". 

When the GGSN 4 wants to inform the SGSN 3 on the data volume 
transmitted or received by a user equipment performing a data 
transmission either at the end thereof or when reaching the 
indicated Data Volume Threshold/ the GGSN 4 sends a "Data 
Volume Notification Request (Data Volume) n to the SGSN 3 
including information on the transmitted and received data 
volume. The SGSN 3 acknowledges this message by returning a 
"Data Volume Notification Response", and sends an appropriate 
charging report message "Apply Charging Report GPRS (Data 
Volume)" to the SCP 6 for correctly .charging the subscriber. 

Fig. 7 illustrates an alternative to both cases of Figs. 5 and 
6. It is possible to add a new parameter, Data Volume 
Threshold, to existing messages (case shown in Figs. 5 and 6) 
or to introduce new messages, Update Threshold Request and 
Update Threshold Response, to carry the new parameter. It is 
e.g. possible to send the data volume from the GGSN to the SGSN 
at PDP context deactivation, and/or at PDP context 
modification. This means adding the data volume parameter to 
existing messages. In such a case, it is not necessary to send 
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the separate messages 'Data Volume Notification Request 1 and 
'Data Volume Notification Response'. 

Similar to the cases shown in Figs. 5 and 6, the embodiment of 
5 Fig. 7 addresses a situation where the charging criteria is 
set, reset, or changed when having a one-tunnel solution. 
Similar to the embodiment of Figs. 5 and 6, this alternative 
comprises the first support node 3 (SGSN), the second support 
node 4 or 5 (GGSN) , and the additional controlling means SCP 6. 
10 The data volume threshold sent by the SCP applies to only one 
data report. If the SCP wants another report, even with the 
same data volume threshold value, it needs to ask it again. 

When the SCP 6 determines the necessity of informing the SGSN 3 
15 on the data volume threshold allowed for a certain subscriber, 
e.g. because of the above mentioned reasons, the SCP 6 sends a 
message "Apply Charging GPRS (Data Volume Threshold)" to the 
SGSN 3 indicating the Data Volume Threshold. The SGSN 3 informs 
the GGSN 4 (or 5) thereon by sending an Update Threshold 
20 Request (Data Volume Threshold) " . The GGSN 4 stores this 

updated Data Volume Treshold and acknowledges the message by 
returning "Update Threshold Response". If the SGSN does not 
receive the acknowledgement message, It knows that the GGSN 4 
(or 5) does not support data volume reporting. 

25 

Like in the case of Fig. 5 and 6, when the GGSN 4 wants to 
inform the SGSN 3 on the data volume transmitted or received by 
a user equipment performing a data transmission either at the 
end thereof or when reaching the indicated Data Volume 

30 Threshold, the GGSN 4 sends a "Data Volume Notification Request 
(Data Volume) " to the SGSN 3 including information on the 
transmitted and received data volume. The SGSN 3 acknowledges 
this message by returning a "Data Volume Notification 
Response", and sends an appropriate charging report message 

35 "Apply Charging Report GPRS (Data Volume)" to the SCP 6 for 
correctly charging the subscriber. 

At PDP context deactivation, the GGSN may send the data volume 
to the SGSN. As an alternative to the Data Volume Notification 



18 



WO 02/03725 



PCT/EPOO/06275 



Request and the Data Volume Notification Response messages, the 
GGSN may send the data -volume in the existing messages used 
e.g. for the PDP context deactivation. If the GGSN initiates 
the PDP context deactivation, the GGSN sends the data volume to 
the SGSN in the Delete PDP Context Request message. If the MS 
or the SGSN initiates the PDP context deactivation, the GGSN 
sends the data volume to the SGSN in the Delete PDP Context 
Response message. 

The GGSN may send the current data volume to the SGSN if the 
data volume threshold -changes . The GGSN may send the data 
volume in the messages used to acknowledge the new data volume 
threshold. The GGSN may send the data volume in the Update PDP 
Context Response message (Fig. 6) or in the Update Threshold 
Response message (Fig. 7). 

The use of the invention is not limited to the above described 
cases, and is also. applicable to cases where e.g. a serving 
node is implemented as a set of separate elements. 

A first example of such implementation is to have part of the 
serving support node implemented in policy server. In 
particular, the check described, in this invention may be 
implemented in such policy server. 

A second example of such implementation is to have the serving 
support node implemented in two separate elements, one handling 
only the control- data (server serving support node) and one 
handling the user plane (user data serving support node) . In 
such implementation, the check described in. this invention is 
used, to determine . if one tunnel (directly from RNC to gateway 
support node) or two tunnels (from RNC to user data serving 
support node and from user data serving support node to gateway 
support node) are established. 
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Claims 

1. Method for connecting a user equipment to a communication 
network having at least a first support node which is able to 
communicate with a second support node, wherein, for 
establishing a connection to the network, the user equipment is 
sending a request to the first support node of the network 
which performs a check whether or not to establish a direct 
tunnel connection between the user equipment, or a controller 
providing the access for the user equipment, and the second 
support node, the first support node establishing the tunnel 
connection between the user equipment, or controller, and the 
second support node depending on the result of the check. 

2. Method according to claim 1, wherein the direct tunnel' 
connection is a tunnel for transmitting only user traffic data, 
the signalling data being addressed from the user equipment to 
the first support node. 

3. Method according to claim 1, wherein the direct tunnel 
connection is a tunnel for transmitting both signalling data 
and user data. 

4. Method according to claim 1, 2 or 3, comprising a step of 
checking whether the second support node is part of the same 
communication network, wherein a single direct tunnel 
connection is established only when the second support node is 
part of the same communication network whereas, when 
recognizing that the second support node is part of another 

20 
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communication network, two tunnels are established, one from 
the user equipment* to the first support node and a second 
tunnel from the first to the second support node. 

5 

5. Method according to any one of the preceding claims, 
comprising a step of checking whether the distance between the 
first and second support nodes is larger or smaller than a 
defined distance value, wherein a single direct tunnel 

10 connection is established only when the distance between the 
first and second support nodes is smaller than the defined 
distance value, whereas, when recognizing that the distance is 
larger than the distance value, two tunnels are established, 
one from the user equipment to the first support node and a 

15 second tunnel from the first to the second support node. 

6. Method according to any one of the preceding claims, 
comprising a step of checking whether or not Lawful 

20 Interception is activated for a user equipment, wherein a 

single direct tunnel connection is established only when Lawful 
Interception is not activated for the user equipment, whereas 
otherwise two tunnels are established, one from the user 
equipment to the first support node and a second tunnel from 

25 the first to the second support node. 

7. Method according to any one of the preceding claims, 
comprising a step of checking whether or not one or more 

30 services activated for a given user will be provided even when 
establishing a single direct tunnel connection, wherein a 
single direct tunnel connection is established only when the 
one or more activated services are provided when having such a 
tunnel connection. 

35 
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8. Method according to any one of the preceding claims, 
comprising a step of checking whether or not interoperability 
between the second support node and the controller is ensured 
when having a direct tunnel connection therebetween, wherein 
the direct tunnel connection is established only when 
interoperability is ensured. 



9. Method according to any one of the preceding claims, 
comprising a step of checking whether or not the creation of a 
correct charging report is ensured when having a direct tunnel 
connection between the user equipment, or controller, and the 
second support node, wherein the direct tunnel connection is 
established only when the correct creation of a charging report 
is ensured. 



10. Method according to any one of the preceding claims, 
wherein the first support node cancels an established direct 
tunnel connection when receiving a request for lawful 
interception of the user equipment, so that both the user 
traffic data as well as the signalling data are thereafter 
addressed to the first support node. 

11. Method according to claim 10, wherein the first support 
node effects a Radio Access Bearer Modification for changing 
the address of the user traffic data to its own address. 

12. Method according to anyone of the preceding claims, wherein 
a packet data transmission is effected, the direct tunnel 
connection being established by giving the user traffic packet 
data sent from the user equipment the address of the second 
node, and by giving the user traffic packet data sent from the 
second node the -address of the user equipment. 
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13, Method according to anyone of the preceding claims, wherein 
the first support node, when receiving a charging-related 
information from a control means, is sending a message to the • 
second support node informing the latter on the charging- 
related information. 



14. Method according to claim 13, wherein the charging-related 
information is a data volume threshold. 

15. Method according to claim 13 or 14, wherein the message is 
a Create PDP Context Request, an Update PDP Context Request, or 
an Update Threshold Request, 

16. Method according to anyone of claims 13 to 15, wherein the 
second support node, after having received the message from the 
first support node, is monitoring a charge-related parameter 
such as the data volume, and is returning charge-related 
information such as the monitored data volume to the first 
support node. 

17. Method according to any one of claims 13 to 16, wherein the 
charging-related information is returned after reaching a data 
volume threshold. 



18. Method according to any one of claims 13 to 17, wherein the 
charging-related information is returned after a change in the 
tunnel connection. 
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19. Method according to any one of claims 13 to 18, wherein the 
charging-related information is returned after releasing the 
tunnel connection, 

20. Method according to nay one of claims 13 to 19, wherein the 
charging-related information or charge-related parameter is 
returned in a Data Volume Notification Request message. 

21. Method according to any one of claims 13 to 20, wherein the 
charging-related information or charge-related parameter is 
acknowledged by a Data Volume Notification Response message. 

22. Method according to any one of claims 13 or 21, wherein the 
control means is a Service Control Point. 

23. Device for connecting a user equipment to a communication 
network having at least a first support node which is able to 
communicate with a second support node, wherein, for 
establishing a connection to the network, the user equipment is 
adapted to send a request to the first support node of the 
network which is adapted to perform a check whether or not to 
to establish a direct tunnel connection between the user ' 
equipment, or a controller providing the access for the user 
equipment, and the second support node, the first support node 
being adapted to establish the tunnel connection between the 
user equipment, or controller, and the second support node 
depending on the result of the check. 

24. Device according to claim 23, wherein the direct tunnel 
connection is a tunnel for transmitting both signalling data 
and user traffic data, or a tunnel for transmitting only user 
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traffic data, the signalling data being addressed, in the 
latter case, from the user equipment to the first support node. 

25. Device according to claim 23 or 24, comprising a control 
means for checking whether the second support node is part of 
the same communication network, and for establishing a direct 
tunnel connection only when the second support node is part of 
the same communication network whereas, when recognizing that 
the second support node is part of another communication 
network, the control means establishes two tunnels, one from 
the user equipment to the first support node and a second 
tunnel from the first to the second support node. 



26. Device according to any one of claims 23 to 25, comprising 
a control means for checking whether the distance between the 
first and second support nodes is larger or smaller than a 
defined distance value, wherein a single direct tunnel' 
connection is established only when the distance between the 
first and second support nodes is smaller than the defined 
distance value, whereas, when recognizing that the distance is 
larger than the distance value, two tunnels are established, 
one from the user equipment to the first support node and a 
second tunnel from the first to the second support node. 

27. Device according to any one of claims 23 to 26, comprising 
a control means for checking whether or not Lawful Interception 
is activated for a user equipment, wherein a single direct 
tunnel connection is established only when Lawful Interception 
is not activated for the user equipment, whereas otherwise two 
tunnels are established, one from the user equipment to the 
first support node and a second tunnel from the first to the 
second support node. 



WO 02/03725 



PCT/EP00/06275 



28. Device according to any one of claims 23 to 27, comprising 

a control means for checking whether whether or not one or more 
services activated for a given user will be provided even when 
5 establishing a single direct tunnel connection, wherein a 

single direct tunnel connection is established only when the 
one or more activated services are provided when having such a 
tunnel connection - 

10 

29. Device according to any one of claims 23 to 28, comprising 
a control means for checking whether or not interoperability 
between the second support node and the controller is ensured 
when having a direct tunnel connection therebetween, wherein 

15 the direct tunnel connection is established only when 
interoperability is ensured, 

30. Device according to any one of claims 23 to 29, comprising 
20 a control means for checking whether or not the creation of a 

correct charging report is ensured when having a direct tunnel 
connection between the user equipment, or controller, and the 
second support node, wherein the direct tunnel connection is 
established only when the correct creation of a charging report 
25 is ensured. 

31. Device according to any one of claims 25 to 30, wherein the 
.control means is adapted to cancel a direct tunnel connection 

30 between the user equipment and the second support node when 
receiving a request for lawful interception of the user 
equipment, so that both the user traffic data as well as the 
signalling data are thereafter addressed to the first support 
node . 
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32. Device according to anyone of claims 23 to 31, wherein the 
first support node, when receiving a charging-related 
information from a control means, is adapted to send a message 
to the second support node informing the latter on the 
charging-related information. 

33. Device according to claim 32, wherein the charging-related 
information is a data volume threshold. 



34. Device according to claim 23 or 33, wherein the message is 
a Create PDP Context Request, an Update PDP Context Request, or 
an Update Threshold Request. 

i 

! 

' _ _ I 

35. Device according to anyone of claims 23 to 34, wherein the 
second support node is adapted to monitor, after having 
received the message from the first support node, a charge- 
related parameter such as the data volume, and to return 
charge-related information such as the monitored data volume to 
the first support node. 

36. Device according to any one of claims 3.2 to 35, wherein the 
charging-related information or charge-related parameter is 
returned in a Data Volume Notification Request message. 

37. Device according to any one of claims 32 to 36, wherein the 
charging-related information is acknowledged by a Data Volume 
Notification Response message. 

38. Device according to any one of claims 25 to 37, wherein the 
control means is a Service Control Point. 
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39. Device according to any one of claims 23 to" 38/ wherein the 

first support node is adapted to request the second support 
5 node to send a data volume report once. 

40. Device according to any one of claims 23 to 38, wherein the 
first support node is adapted to request the second support 

10 node to send a data volume report each time a certain data 
volume is reached based on charging-related information 
received from a control means 

15 41. Device according to any one of the preceding claims 23 to 
4 0, wherein the second support node is adapted to send data 
volume report if requested by the first support node. 

20 42. Device according to any one of claims 23 to 41, wherein the 
second support node is adapted to provide indication on the 
support of the data volume reporting by adding an indication in 
a response message. 

25 

43. Device according to any one of claims 23 to 42, wherein the 
second support node is adapted to provide data volume reporting 
based on data volume limit set by another node or means. 
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